User-Centred Requirements Handbook |
Here a number of task scenarios which represent common or important task situations are listed. These will be used to test the success of the prototype. Usability criteria are also established to help judge the success of the system in relation to the tasks. At least one scenario is required for each user goal.
The strength of scenario development is that it allows design team members and users to consider a range of possible situations and problems and to pose them in the form 'what would happen if...?'. This can test the system against such situations.
A prototype is then developed and tested with these scenarios using a walkthrough (section 4.18) or set of controlled tests (section 4.2) in order to check that the interface provides a usable system, and helps to develop specific usability goals.
Process
A general approach for defining task scenarios is to review the user goals defined in section 1.7. Aim to have at least one scenario per goal. The scenarios should be based on common tasks, difficult tasks, and/or critical tasks. The aim is to test different features of the system design as fully as possible. They should also include characteristics of the user's context such as using a bank machine in the dark or users wearing gloves.
It is also important that the task scenarios reflect the likely changes resulting from the introduction of new systems and facilities. If possible concentrate on the following kinds of task:
• tasks done currently which could be rendered obsolete by the introduction of information systems (for example, remote fault diagnosis might render unnecessary routine maintenance inspection);
• tasks generated by the use of new systems (for example, the need to make backups of information held on the system);
• tasks made significantly easier or more complex by the changes (e.g., the recall and searching of stored information might be easier, whereas issues of security and access might be more complex).
The scenario may be generated by discussion between design team members and users. The following set of steps can assist the process:-
1. For each user goal, review the task steps for current processes and any potential problems listed in form 1.8.
2. Review also the forms containing the context information for the users who contribute to each goal including Form 1.3 User characteristics, Form 1.4 Technical environment, Form 1.5 Physical environment, and Form 1.6 Social and organisational environment.
3. For each goal, produce one or more scenarios in Form 2.3 below reflecting where possible important aspects of context or likely problem characteristics. To do this, write a reference number for the scenario in column 1, including the original goal from which it is derived (e.g. S1(3) - 'first scenario, third goal). Then in column 2 write a short statement to represent the scenario. This should reflect the starting conditions and problems the user might face.
Note that it is possible to cover more than one user goal in the same scenario, as shown in Form 2.3, with scenarios S5 and S6 both covering user goals G2 and G3.
4. Finally in column 3, write down in descriptive form what would be an acceptable outcome in terms of user performance. If appropriate, a measurable performance goal may be stated. This will be used to help assess the user's performance when they try to use the system based on the given scenario.
Form 2.3 - Task Scenarios (example)
| 2.3 Task Scenarios | ||
| System: New bank machine | ||
| User group: General public | ||
| Based on Form 1.7 User goals and Form 1.8 Current processes. | ||
| Ref. | Scenario | Performance Aim |
| S1(1) | The user inserts the card and enters the PIN. They request to withdraw cash. They select £50 and request a receipt. They collect the cash, card and receipt. |
90% of existing bank machine users should be able to carry out this task within one minute. 70% of first time users should also be able to carry out this task within one minute. |
| S2(1) | The user inserts the card and enters the PIN. They request £200, when the limit is £50. | Users should be able comfortably to realise what has happened when they exceed their limit and be able successfully to obtain £50. |
| S3(1) | The user inserts the card and enters the PIN. They request £100, then decide not to proceed with the transaction. | Users should be able successfully to exit the interaction and retrieve their card. |
| S4(1) | The user inserts the card and enters the PIN. They feel threatened by the person in the queue behind them. What should they do? | Users should be able to take some action which allows them to exit rapidly from the transaction and possibly raise an alarm. |
| S5 (2/3) | The machine runs out of money or paper during bank working hours. By some means it is reported to bank staff to replenish. | The bank machine should report the fault to bank staff who should be able to replenish the money or paper within 5 minutes. |
| S6 (2/3) | The machine runs out of money or paper outside bank working hours. | The machine should handle this situation in a helpful way to the bank customer. |
| S7(4) | The user inserts the card without looking at it. It is not accepted by the machine, so the user reorients and re-inserts it. The user forgets the PIN, and tries several attempts. | The machine should handle this situation in a helpful way to the bank customer. |
| S8(4) | The user inserts the card and enters the PIN. They request £100. They receive a receipt but an incorrect amount of money. |
The machine should handle this situation in a helpful way to the bank customer. The system should also allow the bank staff to rectify the situation easily. |